BPF-eBPF 开发路线三：ebpf-go、bpf2go 与 Go 工程集成

我们终其一生，不是为了满足每一个人，而是要找到与自己同频共振的人和事。——村上春树

写在前面

---

• 如果你的主力语言是 Go，那么 ebpf-go 往往是把 eBPF 真正落进工程体系的高性价比路线
• 这一篇会尽量贴近 ebpf-go.dev 上的 Getting Started、Portable eBPF、Object Lifecycle 这些核心主题
• 重点不是只看“怎么生成代码”，而是理解 Go 控制面 + eBPF 对象 + 生命周期 这三者怎么配合

我们终其一生，不是为了满足每一个人，而是要找到与自己同频共振的人和事。——村上春树

---

系列导航

1. BPF-eBPF 学习总览：从概念、机制到工具链选择
2. BPF-eBPF 实战入门：环境准备、最小实验与排错思路
3. BPF-eBPF 开发路线一：BCC 入门、工具使用与自定义脚本
4. BPF-eBPF 开发路线二：libbpf、CO-RE 与 libbpf-bootstrap 实战
5. BPF-eBPF 开发路线三：ebpf-go、bpf2go 与 Go 工程集成

为什么 Go 工程里常选 ebpf-go

ebpf-go 这条路线的最大吸引力在于：

• 用户态控制面直接用 Go 写
• 很适合做 CLI、Exporter、Daemon、Agent
• 不依赖额外运行时去加载 eBPF 程序
• 更容易融入现有 Go 项目的工程体系

如果你的团队本来就大量使用 Go 做平台、可观测性或基础设施工具，那么 ebpf-go 往往比“用户态再写一份 C”更顺手。

先理解 ebpf-go 的基本结构

一个典型的 ebpf-go 工程通常包含：

1. .c 的 eBPF 程序
2. go:generate 指令
3. bpf2go 生成的 Go 绑定文件
4. Go 用户态主程序

这意味着它并不是“纯 Go 即可”。更准确地说：

• 内核态逻辑仍然要遵守 eBPF/clang/LLVM 这套规则
• Go 负责的是对象管理、attach、事件读取和工程集成

bpf2go 到底在做什么

bpf2go 是 ebpf-go 生态里非常关键的工具。

它主要做几件事：

• 调用编译链生成 eBPF 对象
• 为对象里的 program、map、结构体生成 Go 绑定代码
• 让你能在 Go 里更自然地加载和操作这些对象

一个常见的 go:generate 形式大致像这样：

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -target bpfel counter ./bpf/counter.bpf.c -- -I./bpf

然后执行：

go generate ./...

执行完成后，通常会得到：

• 生成的 .go 文件
• 编译好的 .o 文件

一个最小工程应该怎么读

建议你读 ebpf-go 示例时，优先看这条线：

1. .bpf.c 里定义了什么程序和 map
2. bpf2go 生成了什么结构体和加载函数
3. main.go 里如何调用加载逻辑
4. attach 在哪里发生
5. 事件/统计数据如何被读取

不要把注意力全部放在 go generate 命令本身，那只是入口。

官方文档里很重要的一个主题：Object Lifecycle

ebpf-go.dev 里有一个对初学者非常重要的话题，就是 Object Lifecycle。

这件事为什么重要？

因为 eBPF 对象最终和文件描述符强相关，而 Go 又有垃圾回收。

如果你不理解这点，就很容易出现：

• 对象被意外关闭
• attach 成功后又失效
• tail call、pinning 或 map 引用关系异常

所以学 ebpf-go 时，一定要形成这条意识：

• 不是“代码跑完就行”
• 而是“对象、link、map、程序在整个生命周期里何时创建、何时关闭、谁持有它们”

官方文档里另一个重点：Portable eBPF

Portable eBPF 这个主题，本质上和 libbpf 路线里的 CO-RE/BTF 是同一个现实问题：你不能假设所有机器的内核布局都一样。

所以 ebpf-go 的工程实践同样需要重视：

• BTF
• CO-RE
• 稳定的 clang/LLVM 工具链
• 对生成物的构建管理

如果你忽略这些问题，程序在自己电脑能跑，不代表发给别人就能跑。

一个常见的最小主程序结构

用户态 Go 代码大致会做这些事：

1. 提升所需权限或确保运行环境满足要求
2. 调用生成的加载函数
3. attach 程序到指定 hook
4. 创建 ring buffer 或读取 map
5. 循环处理事件
6. 收到退出信号后清理 link 和对象

你可以把它理解成 Go 版的：

• load
• attach
• consume
• cleanup

ebpf-go 最适合什么场景

1. 命令行工具

比如：

• 进程行为观测工具
• 网络延迟分析工具
• 某类资源泄漏定位工具

2. 常驻 Agent

比如：

• 节点侧观测 Agent
• 安全审计 Agent
• 某类内核事件采集守护进程

3. 集成到现有平台

如果你的平台本来就是 Go 写的，比如：

• 监控采集系统
• PaaS / Kubernetes 相关组件
• 内部基础设施控制面

那用 ebpf-go 集成会很自然。

ebpf-go 这条路线最常见的坑

1. 只关注生成命令，不关注对象关系

很多人会背 go generate ./...，但不知道生成出来的对象、map、program、link 之间到底是什么关系。

2. 忽略生命周期

这是最典型的问题，尤其是：

• defer Close() 放错位置
• goroutine 退出导致读取中断
• link 没持有住

3. 把兼容性问题想简单了

即使你是 Go 工程师，也不能跳过：

• BTF
• CO-RE
• hook 差异
• verifier 限制

4. 以为 Go 能替代内核态知识

Go 只是让控制面更舒服，不会帮你自动理解：

• probe 该挂哪里
• 当前上下文允许读哪些字段
• verifier 为什么拒绝这段逻辑

一个适合 Go 工程师的学习顺序

1. 先看总览，理解 eBPF 运行模型
2. 跑一个 libbpf-bootstrap 示例，建立底层直觉
3. 再用 ebpf-go 跑同类型示例
4. 对比两条路线的对象结构和事件传递方式
5. 最后再把它接进你自己的 Go 项目

为什么我不建议“直接只看 ebpf-go”？

因为如果完全没有底层模型，很多概念你会停留在工具层，而不是真正理解 eBPF。

一个非常实用的练手题

建议你做一个“小型进程执行事件观察器”：

1. 跟踪进程执行事件
2. 记录 PID、PPID、comm
3. 用 ring buffer 送到 Go 用户态
4. 在终端实时输出

这个练手题很适合 ebpf-go，因为它能同时覆盖：

• .bpf.c
• bpf2go
• attach
• ring buffer
• Go 事件循环
• 对象清理

最后总结

ebpf-go 真正的价值，不是“让 eBPF 看起来更像 Go”，而是：

• 让用户态控制面更容易工程化
• 更方便接入现有 Go 生态
• 更适合做长期维护的工具和 Agent

但它并不会绕开 eBPF 的底层现实：

• verifier 还在
• hook 还在
• map 还在
• BTF/CO-RE 还在
• 生命周期问题仍然很关键

把这些一起理解，ebpf-go 才能真正用得稳。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

• ebpf-go documentation
• eBPF Docs

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)